Wie wir mit 1Password alle unsere Secrets aus Repos und Deployments entfernen können

In regulierten Umgebungen wie KRITIS gilt: Sicherheitsmaßnahmen müssen dem Stand der Technik entsprechen. Dazu gehört auch, dass Passwörter und andere Geheimnisse nicht unkontrolliert in Repositories oder Deployments liegen. Wenn ein Mitarbeiter das Team verlässt oder ein System kompromittiert wird, müssen alle betroffenen Secrets schnell und nachvollziehbar rotiert werden.

Mit 1Password können wir diesen Schritt gehen. Wir verwalten unsere Secrets gemeinsam, versionieren sie und injizieren sie automatisiert in die Systeme, die sie wirklich brauchen.

Der Auslöser: Ein Gespräch auf der it-sa

Auf der it-sa-Messe sprach ich mit einem Solution-Architekten von 1Password. Ich wollte verstehen, warum unsere bisherigen Versuche, Secrets aus Entwicklungsumgebungen zu entfernen und im Deployment wieder zu injizieren, noch so holprig waren. Das Gespräch zeigte mir, wie viel mehr in diesem Thema steckt – organisatorisch und technisch.

Aha-Moment 1: Mit der 1Password CLI aus dem .env-Chaos zur gemeinsamen Quelle der Wahrheit

Mein erster Aha-Moment: Mit der 1Password CLI (op read, op run) lassen sich Secrets direkt abrufen. Früher musste sich jeder Entwickler für jedes Projekt eine .env-Datei besorgen – oft per Chat oder aus einem gemeinsam genutzten Vault. Das führte zu veralteten Dateien, fehlender Synchronisierung und unnötigem Aufwand für neue Teammitglieder.

Mit der CLI ändert sich das grundlegend. .env-Dateien können jetzt eingecheckt werden, weil sie keine Secrets mehr enthalten, sondern nur Referenzen darauf. Im Repository ist dokumentiert, welche Secrets benötigt werden und aus welchem Vault sie stammen – nicht aber deren Werte.

• op read op://vault/item/field ruft gezielt einzelne Werte ab.
• op run --env-file=.env -- <befehl> löst Secret-Referenzen automatisch als Environment-Variablen auf.

Das Ergebnis: eine konsistente Basis für Secrets, die nicht mehr per Hand verteilt werden muss. Entwickler müssen nur die CLI einrichten und sich gelegentlich per Fingerabdruck authentisieren. Das ist ein kleiner Preis für saubere und sichere Umgebungen.

Aha-Moment 2: Rotation und Compliance als entscheidende Faktoren

In KRITIS-Umgebungen geht es nicht nur um technische Sicherheit, sondern auch um Nachvollziehbarkeit und Compliance. Verschlüsselte Secrets im Repository (bei uns meist SealedSecrets) wirken zunächst praktisch, weil alle Informationen lokal im Projekt liegen. Doch sie erfüllen zentrale Anforderungen an Kontrolle und Auditierbarkeit nur unzureichend.

• Alte Commits enthalten weiterhin alte Secrets. Selbst wenn sie nicht mehr genutzt werden, bleiben sie Teil der Historie.
• Dritte (z. B. GitLab oder externe Partner) haben Zugriff auf verschlüsselte Artefakte, die später durch Algorithmus‑Schwächen oder fehlerhafte Schlüsselverwaltung entschlüsselt werden könnten.
• Es gibt keine zentrale Rotation oder Rechteverwaltung. Jede Projektgruppe müsste selbst festlegen, wann und wie Secrets erneuert werden.

Gerade bei KRITIS gilt: Der Nachweis, dass Secrets regelmäßig rotiert, überprüft und entzogen werden, ist Teil der Compliance. 1Password unterstützt das mit klaren Berechtigungen, nachvollziehbaren Aktionen und zentraler Ablage.

Aha-Moment 3: Projektbasierte Vaults machen Rechteverwaltung erst möglich

Ein weiteres wichtiges Konzept: projektbezogene Vaults mit eigenen Tokens und Rechten. Viele Personen – auch außerhalb der Teams – hatten bisher Zugriff auf mehrere oder alle Vaults. Dadurch war der effektive Zugriff auf Secrets zu breit gestreut und schwer nachvollziehbar.

Projektbasierte Vaults und projektspezifische Zugänge reduzieren den Zugriff erheblich. Nur Teams oder Personen, die Secrets wirklich benötigen, haben Zugriff. Geheimnisse lassen sich gezielt rotieren, ohne dass andere Systeme betroffen sind. Zugriffsrechte können klar pro Projekt definiert werden.

Aha-Moment 4: Service-Accounts als sichere Brücke zwischen Projekten und Deployments

Für Deployments ergibt sich daraus ein weiterer Aha-Moment. Service-Accounts, die nur Zugriff auf den Vault des jeweiligen Projekts haben, sind völlig ausreichend, um ein Deployment durchzuführen. Diese Accounts können im Projekt referenziert werden, während ihre Zugangsdaten in einem separaten Vault liegen, der nur für Deployment-Prozesse zugänglich ist.

So entfällt die Notwendigkeit, dass Entwickler direkte Zugänge zu produktiven Secrets haben. Der Schutz der Produktionsumgebung wird zu einem festen Bestandteil der Infrastruktur und ist keine Frage von Disziplin oder Vertrauen mehr.

🔍 Exkurs: Warum nicht einfach SealedSecrets oder SOPS?

In unserer Umgebung nutzen wir derzeit noch SealedSecrets, um Secrets verschlüsselt im Git-Repository zu speichern. Das funktioniert, löst aber die strukturellen Probleme nicht: Secrets bleiben an den Code gekoppelt, Rotation ist umständlich, und alte Commits behalten alte Secrets.

SOPS ist flexibler, weil es verschiedene Key-Provider (z. B. AWS KMS oder GCP KMS) unterstützt und sich gut in GitOps-Workflows integrieren lässt. Trotzdem bleibt das Grundproblem: Secrets liegen weiterhin im Repository. Wer Zugriff auf den Code hat, hat indirekt auch Zugriff auf verschlüsselte Geheimnisse.

1Password geht hier einen Schritt weiter: Secrets verlassen nie das System. Sie werden zentral koordiniert, revisionssicher auditiert und über CLI oder Service-Accounts nur temporär injiziert. Der Unterschied liegt nicht in der Verschlüsselung selbst, sondern in der Verantwortungszuordnung und der Möglichkeit, Zugriff und Rotation einheitlich zu steuern. Für uns ist das die praktikabelste Lösung.

Fazit: Einheitliche Steuerung als Schlüssel zur Sicherheit – und bitte um Feedback

Kurz gesagt: Lokale, im Repository oder CI-System verschlüsselte Secrets sind bequem, aber langfristig riskant. Eine einheitlich verwaltete Lösung mit 1Password löst diese Probleme. Sie ist auditierbar, kontrolliert zugänglich und vereinfacht die Rotation. Das reduziert Sicherheitsrisiken und macht es überflüssig, dass Entwickler produktive Secrets überhaupt kennen – Deployments ziehen sie automatisch und temporär bei Bedarf.

Ich bin überzeugt, dass wir mit diesem Ansatz den richtigen Weg eingeschlagen haben. Vereinheitlichung, Automatisierung und Trennung von Wissen sind für mich der Stand der Technik.

Was meinst du dazu? Das ist mein aktueller Blick auf diese Herausforderungen. Gibt es Aspekte, die ich noch nicht bedacht habe oder Schwachstellen in diesem Ansatz? Ich freue mich über Feedback, um daraus später einen guten ADR für das Architekturforum zu entwickeln.

Auf der DevOpsCon 25 in Berlin habe ich viel aus dem Vortrag Backup and Disaster Recovery: Business as Usual or What Needs to Change Now? - DevOps Conference & Camps gezogen. Zum technischen Inhalt gehe ich noch mal Separat ein, aber zuerst wollte ich meine Schlüssel-Lernergebnisse auf einer sehr hohen Flughöhe mitbringen.

1. Backups ohne Restore sind nur Datenfriedhöfe

Ein Backup ist kein Wert an sich. Es ist nur die Basis für Geschäftskontinuität – erst der funktionierende Restore bringt das Unternehmen zurück ins Geschäft.

2. Zeit entscheidet über Resilienz

Recovery Time Objective (RTO) ist der kritische Faktor – nicht die schiere Menge oder Existenz von Kopien. Entscheidend ist: Wie lange darf welcher Teil des Geschäfts ausfallen, bis es ernsthafte Schäden nimmt?

3. Kontinuierlicher Minimal-Restore trennt Dauer von Ausfallzeit

Ein innovativer Ansatz ist, kontinuierlich eine schlanke, nicht skalierte Version der Systeme aus den Backups hochzufahren. Damit lässt sich jederzeit beweisen: Restore funktioniert. Und: Die Dauer des eigentlichen Restore-Vorgangs aus den Backups kann nahezu beliebig sein, ohne wesentlich das RTO zu gefährden.

4. Vorhersagbare Skalierung statt unberechenbarer Wiederanlauf

Im Notfall geht es nicht darum, ob das Backup läuft, sondern wie schnell man wieder auf ausreichende Kapazität kommt. Wer Skalierung auf Abruf plant, kennt die Antwort: „In X Minuten / Stunden ist die Leistung verfügbar.“ Das macht den Unterschied zwischen Chaos und geplanter Resilienz.

5. Kosteneffizienz und Compliance in einem

Statt teurer Standby-Infrastruktur entsteht ein Modell, das laufend minimale Kosten verursacht, aber im Ernstfall sofort hochskaliert. Dazu kommt: Unternehmen erfüllen so auch regulatorische Anforderungen nach nachweisbarer Wiederanlauffähigkeit.

Fazit: Backups sind nur der Anfang. Erst wenn Restore und Disaster Recovery gemeinsam gedacht werden – mit kontinuierlichem Minimal-Restore und skalierbarer Infrastruktur – entsteht echte Business-Kontinuität.

Diese fünf kleinen Tools sind echte Arbeitspferde für jeden, der mit Text auf der Kommandozeile arbeitet. Sie haben viele Optionen – aber man braucht nicht alles zu kennen. Schon mit ein paar Grundbefehlen kann man 80 % der typischen Aufgaben lösen.

1. grep – Zeilen finden

grep filtert Textzeilen anhand von Mustern. Praktisch, wenn man in langen Outputs schnell das Relevante sehen will.

Tipps

• -i ignoriert Groß/Kleinschreibung
• -e aktiviert Reguläre Ausdrücke (unter linux gibt es noch -P für Perl-kompatible Regex)

Kombinationen über Pipes machen grep besonders stark:

grep -r -P "def \w*\(" . --after-context 30 | grep "foo" | grep -v "bar"

Für große Projekte lohnt sich ripgrep (rg), weil es schneller ist, .gitignore respektiert und reguläre Ausdrücke standardmäßig aktiviert.

2. cut – Spalten und Zeichen

cut schneidet Spalten oder Zeichen aus Textzeilen heraus. Funktioniert am besten, wenn der Trenner ein einzelnes Zeichen ist.

Bei Whitespace-getrennten Daten stößt cut an Grenzen – da ist awk besser.

3. awk – Felder und Muster

awk versteht Texte als Felder, getrennt durch Whitespace oder ein angegebenes Zeichen. Wenn man möchte, kann man mit awk Text-Dateien fast wie Datenbanken abfragen, aber für den Anfang:

Nützliche Variablen

• NF = Anzahl Felder in der Zeile
• NR = aktuelle Zeilennummer

4. sed – Suchen und Ersetzen

sed ist ein Stream-Editor: ideal für Ersetzungen und einfache Transformationen.

Vorsicht: Nie direkt in die gleiche Datei schreiben mit > – sonst überschreibst du sie, bevor sie gelesen wurde. DAMIT HABE ICH SCHON DATEN VERLOREN Stattdessen:

sed -i 's/alt/neu/g' datei.txt   # Direkt in der Datei ändern

5. tr – Zeichen übersetzen

Beispiel: $PATH lesbarer machen:

❯ echo $PATH | tr ':' '\n' | nl

Fazit

• grep: Zeilen nach Mustern filtern
• cut: Spalten oder Zeichen ausschneiden.
• awk: Felder flexibel verarbeiten und berechnen.
• sed: Ersetzen und transformieren
• tr: Zeichen umwandeln oder löschen

👉 Zusammengeschaltet mit Pipes (|) werden diese Tools zu einem Schweizer Taschenmesser für Textbearbeitung – schnell, skriptbar und überall verfügbar.